The Fibre Channel (FC) protocol enables high-speed point-to-point communications between storage devices through an intelligent collection of switches called a fabric. The storage devices may have one or more node devices called N_Ports which connect directly with ports on the fabric called Fabric Ports (F_Ports). The N_Ports discover each other through the fabric. Any two N_Ports may establish a link by a direct login procedure or a fabric login procedure. Each link is capable of supporting a base level protocol (the FC protocol) as well as one or more upper-level protocols (ULPs) such as the Small Computer Systems Interface (SCSI), the Ethernet Internet Protocol (IP), the Virtual Interface (VI) architecture (FCVI), etc. When running a ULP such as VI, a ULP connection must be established between a pair of ULP N_Ports before communications between the N_Ports can occur.
In many applications, it would be desirable to have multiple N_Ports in a cluster-failover configuration. However, the FC protocol is not well suited to such a configuration. In particular, a ULP port, e.g., a FCVI port (hereinafter called the “source port”) must discover the port identifier (ID) of the corresponding FCVI port (hereinafter called the “login port”) to which it wishes to send a connection request. This is achieved by querying a name server for the fabric to determine the IP address of the login port or by issuing a FARP (Fabric Address Resolution Protocol) request to all ports on the fabric. However, the name server can only associate one IP address per port. Thus, it is not possible to perform a failover cluster by allowing ports to have multiple associated IP addresses or IP aliases stored in the name server.
If a FARP request is the mechanism used to discover the port ID of the login port, then the source port issues a FARP request to all ports on the fabric. The FARP request includes the IP address of the login port. Each port on the fabric receives the FARP request and compares the IP address therein with its own IP address. Only the port with a matching IP address responds to the FARP request by providing its port ID to the source port.
Even if a port were to be assigned multiple IP addresses, the discovery procedure using a FARP request as described above would not be useful in discovering a failover partner node since each N_Port is configured to check if the IP address in an incoming FARP request matches a single IP address stored in the N_Port. Moreover, as defined in the FC protocol, the FARP request is an optional service, and is not supported by all manufacturers.
Thus, there is a need for a mechanism that allows N_Ports to have IP aliases so that the N_Ports may be clustered together as failover partners. There is also a need for a mechanism that allows a failover partner to assume the identity of a failed failover partner in a seamless fashion.